Environment Architecture

Overview#

Our example ChatOps program will need to interact with several services to provide information to users.

To enable this, we have built a more robust version of the Petstore application that we built in our previous sections. This version does the following:

• Implements create, read, update, and delete (CRUD).

• Is gRPC based.

• Has deeper Open Telemetry tracing that flows through RPC calls and records events.

• Deeper metrics can be used to inform Prometheus alarms.

• Replaces logging with tracing events.

• All errors are automatically added to traces.

• Traces can be turned on by a client.

• Traces are sampled by default but can be changed via an RPC.

This new Petstore can be found below. There is a README file that details the architecture if you want to dive into the details, but you do not need to for this section.

Our new Petstore is more capable and will allow us to show some of the power ChatOps can provide by combining our other lessons from this section.

The following is what our service architecture would look like:

There are two services we will concentrate on creating here:

• Ops service: The Ops service does the real work, such as talking to Jaeger, Prometheus, running jobs, or anything else that is needed. This allows us to have multiple ChatOps services running in parallel (which might be needed if our company migrates from Slack to Microsoft Teams, for example). This architecture has the benefit of allowing other teams to write tools using these functions in any language they choose.

• ChatOps service: The ChatOps service acts as the glue between Slack and the Ops service. It interprets messages sent to the Slack bot, which are forwarded to our ChatOps service, and makes requests to the Ops service. It uses the open-source slack-go package, which can be found here.